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(54) DATA UPDATING SCHEME AND DATA UPDATING METHOD 

(57) In a system where a pluraRty of mobile termi- 
nals shares a data of the server, upon issuing an update 
request data of server from the mobile terminals, with- 
out depending on the stability of the communication 
method used by the rndbile terminals, a fair data updat- 
ing t}ecornes possible which only relies on an issuing 
order of the update request In the present system, the 
clock module is provided to all the mobile terminals and 
the server having a synchronized time. The motile ter- 
minal adds the update request issuing time detained 
from the timing module to the update request data UF>on 
Issuing the update request data, and the update request 
data is r^^eatedly sent until the server receives it. Dur- 
ing the repeated transmission, an issuing time attached 
to the update r^uest is ldentk;al to the original issuing 
tinr»e. and the server processes the data update request 
received within the update request reception period in 
an order of the issuing time. 
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Description 

Technical Field 

5 [0001 J The present invention relates 1o data updating systenn and data updating nrtethod for conputer systems. Par- 
ticularly, the Invention relates to the data updating system and the data updating method of a shared data among a plu- 
rality of user tenninals connected to various types o1 communication environment. 

Background Art 

10 

[0002] Problem mX\\ maintaining a consistency of the shared data is occurring at various levels in a conventional com- 
puter system. The protilem of maintaining a data consistency occurs when more than two executing units are sharing 
the data, because each executing un'rt updates the data being shared- Also, when each executing unit has a copy of the 
shared data, a problem o1 how to maintain consistency between an original shared data and the copy o1 the shared data 

15 occurs, and between the copies of the shared data. To give an exannple of how the protilem of maintaining the data con- 
sistency is being dealt within a multj-processor computer oi a shared memory type, if each CPU (Central Processing 
Unit) updates data of the stiared memory, a loss of data consistency is prevented by performing an exclusive control 
based on the data of the shared memory by uang a test-and-set instruction, ar^i by writing the data synchronously. 
Also, when each CPU has a cache memory, a consistency of cache data between CPUs is maintained by applying solu- 

20 tion measures such as write through, copy back and snooping. 

[0003] Another exanple is a case of sharing a fde among processes. This is a case where maintaining a file consist- 
ency is not as strict, although access from a plurality of processes are permitt^. Or, in a case when the data consist- 
ency is very important the exclusive control among processes is provided by uang a semaphoe lock mechanic, 
ahhough this may sacrifice the processing efficiency. Other than the given exampi es, there are lots of technique relating 

25 to the data consistency. To g'rve one concrete example, refer to Japanese Unexamined Patent PuWicafion SHO 62- 
206935 which disdoses a technique to serialize a control fBe access for the exclusive control of a system resource 
using updating queue and procesdng task. 

[0004] A database transaction has one of the major data consistency problem occurring at an application program 
level, for which the present invention is mainly being applied. The transaction includes a discrete electronic business 
30 dealings such as bank account and inventory control. Such transactbn must ratisfy a property known as ACID {Atomic- 
ity. Consistency. Isolation and Durability). In other words, every one of transactions taking place in a system must be a 
transacfion that "cannot be separated", "does not lose data consistency", "is isolated from other transactions" and 
"should never lose data". 

[0005] In order to implement this property, the conventional system has synchronously processed a transaction. Thiat 
35 is. when updating data in a database from a terminal, a series of operation will take place as follows: connects to the 
datat^ase; ot>tains permissk>n to update tiie datatiase; refers to a data and updates ti^ data; issues a ctetabase upctet- 
ing instruction (commit); and completes the series of operation- For exanrple, when a database user wish to update a 
data whk^h is t>eing used t^y another datat>ase user, the updating transaction waits for the database to become available 
in a state of being connected to the database. The series of operatkxi maintains connections to the database and exe- 
^ cuted without inten-upl. 

[0006] tf, the database is cfisconnected during the series of operation, the executing transaction is interrupted and the 
transaction t>ecomes invalid. The coiventional datat>ase system has guaranteed for the data consistency, assuming 
that the series of transaction operation, such as specifying an update data, the exdusive control of update data, a data 
manipulation, and a database updating that will not separate and interrupt, are all guaranteed. 

45 [0007] A technk^ue to expand a futures trading market which has been practiced based on "standing at a dealing ses- 
sion" using a computer system, instead of using a physical place called "dealing sessk>n", is disck>sed in Japanese 
Unexamined Patent Pul>lication HEl 3-505938. Information obtained from attending the "dealing session" is supplied by 
tfie computer system. And a trading mechanism in the "dealing session", or in other words, a transaction mectianism is 
inrplemerrted by the computer system. 

60 [0008] The computer system adopted in tiie present invention, for example, is described in Japanese unexamined 
patent publication HEl 3-50593a By applying the present invention to this computer system, tiie "dealing sessbn" 
whrch this computer system is aiming for can further be expanded. 

[0009] According to the conventional trar^saction processirig. provkSed that an update request of the data from a ter- 
minal is processed synchronously, including a case of using a queuing mechanism such as TP (transaction processing) 
65 monitor whfch aims to adjust a datatDase access load, tiie conventional transaction processing is implemented by set- 
ting the exclusive control mechanism for each transaction processing. To perform a synchronous processing from the 
terminal, a connection status between the terminal and a host (or server) needs be guaranteed by a communication 
protocol of some kind. A quality of communicatton channel is guaranteed by tiie communication protocol to an extent. 
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however, when using a wireless channel such as mobile tel^one and PHS (personal handyphone system), the con- 
nection status of the channel cannot necessarily be guaranteed, including a case of channel cut-off as well as a case 
when a user does not explicitly use the wireless channel. In acWition, a rate o1 transferring is slow. It is predicted that a 
lot of invalid transactions occurs when the transaction processing is attempted from a terminal which uses such wire- 
5 less channel. When the transaction is invalid, the user incurs loss and a load on the system is increased. 

[001 0] The present invention aims to supply the data updating system and the data updating method that can execute 
a data updatir»g trartsaction among the users equally, even when an user may be using a terminal which cannot neces- 
sarily guarantee the connection status. 

10 Disclosure of the Invention 

[001 1] According to one aspect of the present invention, a data updating system comprises a plurality of user ternrti- 
nals and a server for controlling a shared data among usera The plurality of user terminals and the server include clod< 
modules for keeping a time synchronized between the user terminal and the server. The user terminal includes an 

15 update request transmisaon processing unit for transmitting a shared data update request to the server by attaching a 
time obtained from the clock module as a data update issuing time when representing a shared data updating, and for 
repeatedly transmitting the shared data update request in keeping the data update issuance time unchanged until the 
shared data update request is received by the server. The server includes a shared data control module for deciding an 
updating order of the shared data update request based on an attach«J data update Issuing time of the shared data 

20 update request receiv«j from the user terminal. 

[0012] According to ancrther aspect of the present invention, the data updating system comprises the sfiared^data 

control module which includes an update rule control unit tor settir^g an update request rec^tion period, and an update 
request control unit for receiving the shared data update r^uest received within the update request reception period. 
[001 3] According to another aspect of the present invoTtion. the data updating system connprises the update rule con- 

25 trol unit which further sets a valid update request issuance period which is included in the update request reception 
period. The update request control unit receives a shared data update request for which a data update request issu- 
ance period of the shared data update request received is within the vafid update r^uest issuance period. 
[0014] According to another aspect of the present invention, the data ipdating systOT comprises the update data 
request transnrossion processing unit which transmits the shared data update r^juest including a data updating condi- 

30 tion to the server. The ^wed data control module includes a data updating unit for checking the data updating condition 
included in tiie shar^ data update request in an order of data update request issuance time after tiie update request 
reception period expires, dedding a shared data update value based on the shared data update r^uest wtien the 
update condition Is met, and updatir^g the shared data to the shared data updating value. 

[001 5] According to another a^sect of tiie present invention, the data updating system connprises the data updating 
36 unit which checks the data updating condition Included in the shared data update request which is already received 
within the vafid update request Issuance period in an order of tiie update request issuing time, and decides a shared 
data update predicting ^^ue based on the shared data update request when the update condition is met 
[0016] According to another aspect of the present invention, the data updating system corrprises the shared data 
control module which includes a user rxrtif rcation unit for giving one of permissions to the user tenninal from permls- 
40 sions classified by strengths, and for selecting information which is transmitted to the user terminal based on the per- 
mission. 

[001 7] According to another aspect of the fxesent invention, the data updating system comprises the user notification 
unit which transmits an update fog of the shared data only to a user terminal having a permission of a certain strengtii, 
[001 8] According to another aspect of the present invention, the data updating system comprises the user notification 
45 unit which transmits a cont^t of ttie data updating request received from the user ternninals only to a user termir>al hav- 
ing a permission of a certain strength. 

[0019] According to another aspect of the present invention, the data updating system comprises the sfiared data 
control module wtiich includes a user notification unit for notifying the shared data to the user terminal when the shared 
data Is updated. 

60 [0020] According to another aspect of the present invention, the data updating system comprises the user notification 
unit which includes at least a differential data between the shared data before updating and after updating in a content 
of the notification. 

[0021 ] According to anoth©' aspect of the present invention, the data updating system comprises the user notification 
unit which notifies to a user terminal that has accessed the shared data before updating the shared data. 
65 [0022] According to another aspect of the present invention, the data updating system comprises the user notification 
unit which notifies to a user terminal that has accessed the shared data within a pre-determined period t>efore updating 
the shared data. 

[0023] According to anotho' aspect of the present invention, the data updating system comprises the user terminal 
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which transmits an inlormalion transnnission request 1o the server. The shared data control module includes a user noti- 
lication unit for receiving the information transmission request irom the user terminal, for checking an access log. and 
for responding to the information transmission request If the user terminal has accessed the shared data before receiv- 
ing the information transmission request 
5 [0024] According to another aspect of the present invention, the data i4Xjating system comprises the user notification 
unit which responds to the information transmission request if the user terminal has accessed the shared data within 
the pre-determined period before receiving the information transmission request 

[0025] According to another aspect of the present invention, the data updating system comprises the information 
transmission request from the user terminal which is a transmission request of the content of the data updating request 

ro already arrived to the server before a shared data updating process. 

[002$] According to another aspect of the present invention, the data updating system comprises the user terminal 
which transmits a condition for monitoring the shared data updating. The shared data control nrujdule includes a user 
notification unit for registering a transmitted condition, and for notifying the shared data updating to the user terminal 
when the condition is met at the shared data updating. 

15 [0027] According to another aspect of the present invention, the data updating system comprises the user terminal 
which transmits a condition for monitoring the shared data updating. The shared data control module includes a user 
notificat'on unit for registering the transmitted condition, and lor notifying to the user terminal that the shared data 
updating predicting value meets the condition when the shared data updating predicting value meets the condition. 
[0028] According to another aspect of the present invention, the data updating system comprises the dock module 

20 which includes an encryption unit. 

[0029] According to another aspect of the present invention, the data updating system comprises tine dock module 
which indudes a user ternnnal authentication function. 

[0030] According to another aspect of the present invention, the data updating system comprises the server which 
includes a menrK)ry unit for storing a shared data updating request queue, and for arranging the shared data update 
2S request received from the user terminal by the shared data control module in an order of the data update request issu- 
ance time. 

[0031 1 According to another a^ct of the present invention, a data updating method for a computer systems having 
a plurality of user terminats, and a server for controlling the shared data anxxig the users, wheren the plurality of user 
luminals and the server respectively have clock nr^ules for keeping a time, the data updating nr»ethod cortpr'^ng the 
30 Steps of: 

synchronizir^ a time between the dock modules of a plurality of user terminals and Ihe clock module of the server; 
by the user terminal, attaching a time obtained from the dock module as a data update request issuance time to a 
shared data update request when requesting a shared data iqxlate. and transmitting the shared data update 
35 request to tiie server, and repeatedly transmitting the shared data update request in keeping the data update 
request issuance time urx^hanged until the shared data update request is received at the server: arKi 
by the server, receiving the ^red data update request from the user terminal and d«;iding the updating order of 
the shared data teased on an attached data update rec^est issuance time attach^ to the stored data update 
request received. 

40 

[0032] According to another aspect of the present invention, the data updating method, wherein the shared data 
update request which is one of a selling order and a txiying order which indudes a first condition and a quantity, wherein 
the shared data update request is stored in a memory unit of the server in a formal of shared data update request qu^e 
in an order of the data update request issuance time, 
45 wherein the data updating method comprises the steps of: 

a) checking by executing one of the steps of (a1) to (a3). depending on a state of the shared data updating request 
queue stored in the memory unit of the server; 

a1) completing the data updating process when neither the selling order nor the buying order is stored in the shar^ 
so data update request queue stored in the memory unit of the server; 

a2) talcng the buying order as a main order and taking tiie selling order as a dealing order when a top of the shared 
data update r^uest queue stored in the memory unit of the server is tiie buying order, and advancing to a first con- 
dition comparing step (b}; and 

a3) taking the selling order as a main order and the buying order as a deafing order when a top of the shared data 
55 updating request queue stored in the memory unit of the server is the selling order, and advancing to the first con- 
dition comparing step (b); and 

b) comparing the first condition by reading tiie dealing order in an order from the shared data Lqxiating request 
queue stored in the memory unit of the server, and executing one of the steps depending on an availability of a 
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dealing order that matches in the first condition with the main order; 

b1) if there is no matching in first condition, deleting the main order from the shared data update request queue 
as a non-established main order and retuming to the checking step (a); 

b2) if the first condition matches, comparing the buying quantity and the selling quantity, and executing one of 
the following st^s based on a result of comparing; 

b21) "rf the buying quantity is exceeding the selling quantity. non-eslaWishing the buying order and the sell- 
ing order, and reading a next dealing order from the shared data update request queue, and returning to 
the first condition comparing step; 

b22) if the buying quantity is same with the selling quantity, establishing the buying order and the selling 
order, deleting the buying order and the selling order from the shared data update request queue, and 
returning to the checking step (a); and 

b23)rf the selling quantity exceeds tfie buying quantity, estatrfishing the selFing order and the Ixiying order, 
deleting the buying order from the shared data update request queue, and replacing selling quantity to an 
exceeding buying quantity, updating and storing the queue data of the selling order, and returning to the 
checking st^ (a). 

Brief Description of the Drawings 

[0033] 

ng.1 illustrates a configuratk>n of the system adopted in the present inventkxi; 

ng.2 illustrates an exanple of incorporating a timing module of the present invention; 

Fig. 3 illustrates a block chart of the timing module of the present invention; 

Rg.4 illustrates a configuration of shared data control server of the present invention; 

Rg.S illustrates a configuration of shared data control module of the present invention; 

Rg.6 illustrates an example of input screen of a terminal application ustr>g the present invenfion; 

ng.7 illustrates a flow chart of shared data update Issuing process of the present invention; 

ng.8 illustrates an exanple of the shared data update request data of the present invention; 

ng.9 Illustrates a f tow chart of shared data update request data of the present invention; 

Rg. 1 0 illustrates a flow chart of the shared data update process of the present invention; 

Rg.1 1 illustrates an exanple of user ID data of the present invention; 

Rg.12 illustrates a flow chart of notification service registration process of the present invention; 
Rg.1 3 illustrates a schematic diagram of data monitoring registration queue of the present Invention; 
Rg.1 4 illustrates an example of shared data update request queue of the present invention; and 
Rg.1 5 illustrates a schematic diagram of rxjtiFication service registration senrtce of the present invention. 

Best Mode for canTing out the Invention 

EmlxxJiment 1. 

[0034] The data updating system of the present irwention will be described witii reference to the drawings of ngs.1 
to 1 3. The present invention describes a commodities excfiange system as an adopted example, however, tills ©cample 
is one type of transaction system partidpated by a plurality of users. The commodities exchar^e system provides a vir- 
tual market, and participation to the market is only possible from terminals provided by tiie system. The participants are 
not only restricted to a wired terminal, but tfiey can also be a wireless terminal, so that all the users can participate in 
the market equally. 

[0035] Rg. 1 illustrates three different cases of partidpation by the users. These includes a case of participating from 

wireless terminals 101 and 102 to a tiase station 107 using a mobile telephone cfiannel. via a putrfic network 108. There 

is a case of partidpating from terminals 103 and 104 tiTat are connected to an intranet which is connected via a pubilic 

lin 1 09 and a personal computer PC There is also a case of participating from terminals 105 or 1 06 that are connected 

to a same LAN (Local Area Network) connected to a server 110 which controls a shared data. 

[0036] The configuration of the data updating system will t>e described next, however, from hereinafter the wireless 

terminals 101 and 102 and tiie terminals 103 to 106 will simply be referred to as a user terminal. 

[0037] As shewn in Fig.2, the user terminal partidpating in the present system is provided with a user dock module 

201 having a time keef^ng function, and a server 110 having a server dock nrwjdule 402. Also, the user terminal 101 

installs a terminal communication program 202 for b'ansmitting and receiving data or information betwe^i the user ter- 
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minal 101 and the server 110. The terminal communication program 202 is one example of an update request trans- 
mission processing unit. The update request transmission processing unit has a function oi transmitting a shared data 
update request which will be described later. 

[0038] The terminal communication program 202 can only be used by a specific user, so it should have a function to 

5 confirm the user using a passwcrd. In each user terminal, a memory 203 is ir^talled. 

[0O39] A same user clock module 201 is used in all of the user terminals, including the wireless terminal 101 . The 
user dock module 201 is removable from and attachable to all the user terminals. The user dock module 201 becomes 
valid when authenticated by a system controller and when its time is adjusted to a standardized time adopted in the 
present system. Then the user dock module 201 is distributed to the specified users only. As an example, for a case oi 

10 adopting the system in the commodities exchange nnarket. the system controller should be performed by an inspecting 
organization in the market, and the system controller strictly controls the user dock module 201 . 
[0040] In the present system, a PC card is used to implement the user clock nruJdule 201 . 

[0041] Rg.3 illustrates a functional block chart of the user dock nrKxiule 201. Description of the numbered compo- 
nents indicated in the drawir>g of ng.3 folk>ws: a PC card interface logic 301 : an inner bus 302; a brack-up t>attery 303; 

15 a control logic 304 for encryption; a dock 305; and an erasable programmable read only memory (EPROM) 306. The 
control logic 304 incorporates a time adjusting fx>st authentication logic. The control togic 304 has an initiaJ setting of 
adjusting the clock 305 to the standardized time of the present system, which will be described later, and an initial set- 
ting of user authentication data to the EPROM 306. The user dock module 201 becomes vafid t>y these initial settings. 
[0042] Such initial settings oi the time adjustment and the user authentication data are performed by the system con- 

20 troller. 

[0043] The terminal communication program 202 examines whether the user dock module 201 is installed in the user 

tQ'minaL H the user terminal is found to be instalfing the user dock module 201 . tiien transmitting and receiving of data 

or information become possftjie, ljut only after a correct password is entered l>y the user, the terminal communication 

program 202 can be used Irom tiie user. 
25 [0044] ng.4 illustrates a functional configuration of the sen/er 110 which is a shared data controller of the present 

systenx The shared data in the present system is a data record from each table of a datatiase. 

[0045] The server 1 10 is used by the plurality of us^s connected to a LAN 401. A server dock nrxxlile 402 gives a 
. standardized time of the preserrt system, and has a clock whbh will become a standard for the user dock module 201- 

[0046] The user dock module 201 acfjusts its ck>ck accordirig to the dock of server ckxk nrKxJuIe 402. 
3o [0047] Description of the numbered conrponents indicated in the drawing of Fig.4 follows: an update request storing 

disk 403; a shared data control module 404; a shared data storing disk 405; a memory 406; and a user control table 

1 100, which will be descrtoed later. 

[0048] As shown in Fig. 5. a shared data control module 404 receives a request for updating the shared data from a 
user, and conrtprises the following parts: an update request corrtrol unit 501 for receiving and storing the request for 
35 updating the ^Tared data from the user; a user notification unit 502 for performing a notification service of a data updat- 
ing status to the users; an update rule control unit 503 for s^ng a perfod of receiving the request for updating the 
shared data and for performing an arbitration for the update of the shared data; and a data updating unit 504 for updat- 
ing the shared data from an an^anged (queued) update request data. 

[0049] Followings are operations of the present system described based on functions 1 to 6. 

40 

1 . functions of entering a r«iuest for updating data at the user terminal and transmitting the entered request 

2. update rule control function 

3. shared data update request corrtrol function 

4. data updating functk>n 
45 5. price estimation function 

6. rectification function to update content access user 

1 . functions of entering a request for updating data at the user terminal and transmitting the entered request F^rst, 
a transmitting functfen of the i4xJate request of the shared data at the user terminal is descrtoed. A comnrwnication 
60 media to be used by the user Is not mentioned, however, a mechanism including an issuance of the update request 
from tfie user terminal and a registration of the update request to the update r^uest control unit is described A 
communication re-trial mechanism is also descrS^. 

The user ternrdnal has a PC card interface. When the user dock module 201 is incorporated in the system and 
when the terminal communication program 202 recognizes that a correct password has been entered by the user, 
65 then the terminal communication program 202 in the user terminal Incomes ready to use. 

As described prevk>usiy, the example of adopting the present system to tfie commodities exchange system is 
described. Rg.6 (a) illustrates a screen of buying order prepared by the terminal communication program. 

An order screen 601 sets the following conditions in a dialogue format: a product ID (identification); a bnjylr^g 



6 



EP0 952 510A1 



quantity; and a buying price. Fig.6 illustrates the product ID of oranges harvested in mid-February. 

To the buying quantity, "just", "max" or "min" options are attached, indicating whether the buying quantity 
equals to, less than or greater than, respectively. An upper limit price is set as the buying price. In the example of 
Fig.6 (a), the buying quantity of about 200 is being indicated. 

After setting the product ID. the buying quantity and the buying price, the user alter checking the display screen 
presses a send button 602. 

Alternatively, the options "max" and "min" can be used together as in expression indicated below. 100 < buying 
price < 200 

Fig.6 (b) is a screen for selling order. To this order screen 603. after inputting the product ID as in a case of the 
buying order, the user inputs a selling quantity. Unlike a case of the buying order, the options are not attached to 
the quantity for a case of selling, and the lower limit price is input as a selling price. 

After setting the product ID. the selling quantity, and the selling price, the user after checking the screen 
presses a send button 604. 

TTie buying price and the selling price is a first condition in the present invention. 

When the user presses the send button 602 or 604, the terminal communication program 202 sends the buying 
order or the selling order, or in other words, sends the shared data update request to the server 1 1 0. based on the 
server address registered as a configuration data and based on the communication media t>eing used. 

Sending procedures of the terminal communication program 202 1o the server 110 after entering the buying 
order and the selling order from the user is descrit>ed with reference to a flow chart of Fig.7. 

The terminal communication program 202 provides dffferenl screens for the buying order and the selling order 
to prevent an operation error. However, as the updating process, the procedures are identical for both cases, so the 
buying order only will be descrit^ed below. 

In the first process of step 701. a server address Is obtained from the user dock module 201. In the present 
system, the server address is expressed using an IP (internet protocol) address. 

In step 702. a data of the buying order provided from the user is organized into a fomnat that can be accepted 
by the user dock module 201. In step 703. the formatted data of the buying order is inputted to the user dock mod- 
ule 201. Rom this input, the user dock module 201 creates an update request data 800 having a format sfiown in 
Rg.a Then, the us&r dock nxxJule 201 encrypts the ifxiate request data 800 using an encryption key which is pro- 
vided at a time of thQ initial settings. 

The update request data 800 rndudes the followings: a user ID 801 who specifies the user; a tran^nission time 

802 which Is a time when the update request data is issued, which is obtained from tiie dock module: a table ID 

803 showing a product genre; a record ID 804 which is same in context as the product ID; an operation e05 for the 
quantity data (subtraction for buying and addition for selling); a quantity (operancQ 806; a condition 807 for deciding 
operation execution: and an user's payment bank account 808 for carrying out a payment transaction acconrpanied 
with the shared data updating. If the operation 805 is subtraction, that is. the kxjying order, the condition 807 auto- 
nratically represents an upper limit value of the buying price. If the operation 805 is ackfrtion. that is. the selling 
order, the condition 807 automatically represents a lower limit value of the selling price. 

The qpdate request data 800 of Rg.8 illustrates the buying order induding the transmission time of year 1997. 
month of September, 17th day, 1 1 hours 3 minutes 32.12 seconds, tiie table ID of fruit, the record ID of oranges har- 
vested in mid-Febaiary, quantity of about 200. and the buying price of less tfan 350. 

TTie lemiinal communication program 202 receives an encrypted update request data 800 from the ckxk mod- 
ule 210 (step 704). The terminal communication program 202 sends the encrypted update request data 800 to the 
server in step 705. 

As described prevk>usiy, the transmission of the update request data 800 to the server does not necessarily 
will be successful always, depending on the communication media being used by tfie user terminal at tiie time. The 
user tenninal attempts a re-trial of the transmission to the server until the comnnunf cation is successful. Even in the 
case of re-trial, the terminal communication program 202 will rxjt alter the transmission time 802 in the update 
request data 800, and re-sends it containing the same fransmlssion time 802 as the initial transn^ssion lime. By 
doing so, even if the user utifized a terminal that does not necessarily guarantees the connection status, it becomes 
pos^t)l6 to supply the data updatir^ sysiem and method tiiaf can execute the data update transaction equally 
among tine usera For tiie present system, as the communication protocol, a transaction control protocol (TCP) is 
being used, therefore, whether the update request data Is sent successfully or not to the sender will definitely be 
known. 

The encrypted update request data 800 is valid as long as it reaches the server during an update request 
reception period. Therefore, if the transmission fails, the user can use another conrvnunication media in serving the 
update request data 800 stored in the user terminal. Of course, the user terminal can also store the update r«|uest 
data 800 inside a ntemory 203. 

When the update request data is received, the server 1 1 0 sends a receiving message to the user terminal. In 
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step 706, the user terminal receives the receiving message from the server 110, recognizes whether the server 1 1 0 
has received an update request or not (note that the update request may not be received by the server for a case 
outside the reception period), and notifies to the user. 

5 2. Update rule control function 

The update rule control function, which is held by the update rule control unit 503, has the following functions: 

controlling an i^xiate request reception time of receiving the ipdate request; controlling a validation of issu- 
ar>ce time of the update request; and controlling of the shared data update. 

10 

In the present embodiment, the adopted example is the commodities exchange. An update request reception 
period is set to 9 a.m. to 9 p.m., and a valid update request issuance period is set to 9 a.m. to 3 p.m.. These periods 
are finnly set to a configuration data file which is accessed, referred and nnanaged by the update rule control func- 
15 lion. 

The valid update request issuance period is expected to correspond to a general business hour d a market- 
place, and only those buying and selling orders that are issued during these hours are valid. 

The orders that are issued during the vafid iqxJate request issuance period, depending on the communication 
cortdition. arrives to the server with some delay, therefore, taking into account a possible delaying time, the orders 
20 that arrived within the update request reception period are received by the server. 

A data update processing is commenced after the completion of the reception at 9 p.rTi.. 

3. Shared data update request control function 

This function, held by the update request control unit 501 , Is a function to receive the shared data update request 
25 from a user. By receiving the update request from the user, the update request control unit 501 creates and controls 

an update request queue. A ticw of the process Is descr3:>ed using Fig.9. 

This process is operated uang an independent context, and is always monitoring for an arrival of the update 

request from the user terminal. Strictly speaking, a new context is created by an arrival of connect request, and 

after olJtaining one of global locks found in the updating request queue, the processes from step 901 onwards are 
30 performed, however, in this example, the flow is illustrated as a loop process. Wh©i the updating requests arrived 

in parallel, the process will be serialized, however, this has no effect on the equality of the transactions among the 

users. 

When the encrypted update request data 800 is received at the step 901, this update request data 800 is 
decrypted to obtain the update request data illustrated in Rg.8. 
35 In step 902. the user ID of the ifxiate request data is checked, and if the user ID is unauthoriz^J, then in step 

906 the user is notified that the update request is not regist^ed due to the unauthorized ID. 

Following in step 903, an inquiry Is made to the update rule control unit 503 to check whether a transmission 
time attached to the update request data 800 is within the vafid update request isstflnce period or not arvl checks 
whether its arrival time is within the update request rec^ion period or not H neither is found to be within these pre- 
40 determined periods, then the user is notified that the update request registration is rejected, accompanied by the 
reason. In siep 906. 

If in step 903, the transmission time and an arrival time of tfie update request data 800 is found to be within the 
pre-determined periods, then in step 904 two queue link poirrters are attached to the update request data 800 for 
registering to the update request queue, and a user address is attached to the update request data 800 as the 
45 returning address to the user, and the update request data BOO is queued to the update request queue in an 
ascending order of the transmission time (in an order of eariiest time). 

An example of configuration of the update request queue formed in a memory 406 is illustrated in Rg, 1 4 (here- 
inbelow simply referred to as a queue). A header 1401 for controlling the update request queue is illustrated in 
Rg.14. The header queues three queue data In addition to the update request data 800 dTown in ng.8, the queue 
60 illustrated in Fig. 14 includes the foltowings: a queue link pointer 1403 indicating a previous queue data of the 
queue; a queue fink pointer 1 404 showing a next queue data; and a user address (port address) 1402. Each qu«je 
data has a fixed length, and uses a sufficient size of a memory area for queuing. This region is called memory pool. 
With this memory pool, re-using of the memory area is possible by an operation of the queue fink pointer. 

Furtiier, in st^ 905, a content of the memory pool is written to an update request storing disk 403 (one axam- 
55 pie o1 memory unit) corresponding to the menrx)ry pod of the update r^uest queue. In step 907, the reception and 
the registration of the update request at the server 1 10 is notifi^ to the user. 

Furttier. in step 908. the update request data 800 is transfen'ed to the users who are pre-registerir)g a request 
for transferring tiie update request data 800. The registration for the transfer request of the update request 800 will 
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be described in ihe following section "6. Notification function to update content access user. 

When Ihe system fails due to some trouble, the update request queue is restored to ttie memory 406 by read- 
ing the content of memory pool from the update request storing dsk 403. 

4. Data updating function 

This function Is possessed by the data updating unil 504. Following mechanisms are particularly described: func- 
tional operation by the update rule: de-queue of the update request data 800; and a checking mechanism of the 
update request. 

In the present system, the data updating function Is activated at 9 p.m. of the business day by the update rule 
control function. In the present embodiment, as a result, the data update is processed in batch, however this does 
not limit the present invention. 

The present data updating process is described using a flow chart of Rg.10. 

Already, the update request queue is being an-anged based on the update request issuance fime of Ihe user 
for every record, therefore, the updating process processes the queue data by accessing the update request queue 
in an order of the oWest issuing time for all records in step 1 00 1 , and de-queues (deletes) a processed queue data. 
The processing completes when all the queue data in the update request queue are processed. 

In step 1 002. the buying orders and selling orders from the update request queue are collated. If a queue data 
situated at a top (rf the update request queue, which has the oldest update request issuance time within unproc- 
essed queue data, is a buying order, then queue data of the selfing orders are searched in an ascending order, and 
checks for a selling price that matches the price in step 1 003. If a matching sdfing price is found, that is, if the sell- 
ing price ^ buying price, then further in step 1004. the selling quantity and the buying quantity are compared. If the 
seinng quantity satisfies the buying quantity, that is. if the selling quantity ^ buying quantity, then a deal is estab- 
nshed and the price is registered in the database Then in step 1010. the established queue data of the selfing order 
and the queue data of the buying order are de<iueued. At this time, when the selling quantity is greater to re^H in 
a remainder, that Is, selling quantity > buying quantity ( remaind®* quantity = selling quantity - buying quantity ), the 
seinng quantity is re-set to the renrtainder quantity. An established queue data of the buying order Is de-queued 
(step 1010). If the price or the quantity does not match, the flow returns to step 1002 to search ior a next candidate. 
However, if the quantity is not satisfied, the queue data of selfing order is continuou^y read to search for the s^fing 
quantity and the selling price that satisfies the buyer, and if there is no selfing ofder that matches the buyer's con- 
dition, this buying order is not established at all. The queue data of buying oKier not established is de-queued (step 
1 009). In the case of buying order described above, the buying order is a nnain order, and salfir^ order is a deafing 
order of the present invention. 

H the queue data at the top of the update request queue is the selfirtg order, a same processing is performed 
for the buying order. In the case of this selfing order, the selling order is the main order, and the buying order Is the 
dealing order of the present invention. 

For the buying orders or selling orders that are not estafcrflshed. as well as those selling orders that has remain- 
der after seariching to the end, are drawn out from the update request queue as the remaining order at a time of de- 
queuing. As described above, regardless of whether the orders are established or not. and the lop queue data Is 
deleted (de-queued) from the update request queue. The deletion of queue data is performed by replacing the 
pointer of the header. Accordingly, the queue data moves in order to the top for processing. 

If the buying and selling are established, that is. if the updating condition matches, in step 1005. the shared 
data is updated using the operation 805 (subtraction for Ixjying. and addition for selfing) and the operand 806 (prod- 
uct quantity in the present system) which are set at the update request data. In other words, a data of the record in 
the database in use Is updated. Also, a payment accompanied by the buying and selling of the product is can-ied 
out using the user's payment bank account 808 set inside the update request data 800. 

When Ihe shared data updating is complete, a user who Issued the update is notifi^ that the buying and sell- 
ing orders are estabfished. and the shared data update is notified in step 1006, through the user notificatkxi unit 
502, 

The notification to the user is done at a nighttime, K) the us©- terminal may not be operating, however, those 
notification that were not received by the user during this time will be re-transmitted again when the user terminal 
is operating. 

Also, the user can inquire for a result of the update request that they transmitt^ by using the terminal commu- 
nication program 202. 

Further, in step 1 007. a differential data of a record before updating and a record after updating is transmitted 
to a user who is pre-registering for a shared data update notification r^uest The registr^on of a request for 
shar&i data update notificatfon is described in the followirTg section "6. Notification funchon to tpdate content 
access user". 

H the orders do not match the conditions, that Is. for the remaining orders, then in step 1008. the fact that the 
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shared data updale was not performed is nolilied 1o the user who issued the update request. This notification is 
sent to the port address registered in the update request queue. 

5. Price estimation function 

5 This function is possessed by the data updating unit 504. jusi like the data updating function. 

The data updating function makes a final decision of the buying and selling prices by collating the queue data 
of buying order and selling order when the updale request reception period expires (in the present embodiment 
after 9 p.m.). The price estimation function collates the queue data storing the buying and selling orders which are 
received during the valid updale request issuance period (9 a-m. to 3 a.m. in the present embodiment) in a pre- 

10 determined interval (every 10 minutes, for example), and takes the buying and selling prices established at that 
instance as a predicting value of the price. In this time interval, there is a possibility of the orders that are being 
already transmitted but not received, and they may include an order that has a different price from what is formally 
deeded after starting the data updating function. For this reason, the predicting value is treated as a value to allow 
tor an error, 

15 When a plurality of the buying and selfing orders are estaWished within the pre^Jetermined interval, its maxi- 

mum value and minimum value are taken as the proofing values. Alternatively, an average value nnay be taken as 
the predicting value. 

6. NotTication lunction to update content access user 

20 This function is possess^ by the userjiotification unit 502. 

[0060] In the present system, wh^ the user is registered to the server 110 using the user dock vnodu\& 201 . the user 
ID is registered as a control data of tine server 110. however, in doing so. a permission of tfie user is also registered to 
tfie server 110. The permission reflects an actijal dealing result in the product dealing market and depending on a 
25 given pern^ssion, the user can use a data r^emng sen^ice whrch will be deserved later on. The pemnission is given in 
tilree types from permission 1 to permisaon 3. Each permission is descrtoed below. 

1 . Permission 1: a user can receive a notification when the shared data updating is completed. Specifically, in the 
present system, the user can successively refer to data of approved product dealings after 9 p.m. from the notrf ica- 

30 tion. The permission 1 is a permission which enables to receive the shared data update notification previously 
described in "4. Data updating function". 

2. Permission 2: a user can receive a content of the shared data update request handled by the server before 
updating the shared data. The pemiission 2 can succes^vely receive the content of update request data which is 

35 anived from tiie commencing time of the market 9 a.m. until the update reediest reception period expires, and tiiis 
enables the user to obtain the most recent market trend. Also, based on pre-approved update r«?uest data, the pre- 
dicting value of the mart<et trend is obtained. TVie pemnission 2 Is a permission which can transfer the update 
request data whtah is previously descrtoed in "3. Shared data update request control function''. 

40 3. Permtssbn 3: a user can obtain an tpdate log of tiie shared data of a past- The permission 3 enables the user 
to obtain the update kjg of the shar^ data tiTroughout the past The permission 2 includes tiie pernrtission 1 . and 
the perntssion 3 includes tiie permission 1 and pemiission 2. The permission of the user is registered as 1. 2 or 3. 
When an user requests for a registration to the data refemng service, the user is registered to tine data referring 
service by checWng the permission. 

46 

[0051 1 Prior to describing tiie data referring service, ttie user registration to the data refen'ing service Is described first 
[0(^] Rg. 1 1 illustrates a user control table 1 1 00 of the system which conti-ols a registered content The user control 
table 1 100 is stored in the update request storing disk 403. The user ID is stored in the user control table 1 100. Tlie 
prevk>usly descrtoed permission is registered in 1 1 02. Log of tiie shared data update request issued by tiie user is reg- 

60 istered irom 1 1 03 onwards. 

[Q<^] Witfi regard to updating a database in tiie system of the present invention, a shared data access is performed 
by requesting to ttie server 1 1 0. However, wrth regard to reading a database, it is performed by tiie user directiy access- 
ing to the database. Accordingly, the present embodiment only focuses on an issuance of ttie shared data update 
request as an access log, however this does not fimit the present invention. 

66 [0054] Fig. 1 2 illustrates a flow of tiie user registration process of tfie update content notification service. 

[0055] The user registration process f tow illustrate in Rg. 1 2 is used by tiie shared data update notif ication service 
corresponding to the permission 1 . and used by a successive reporting service of tiie update request data conrespond- 
ing to the permission 2. 
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[0056] In step 1201 , a request tor the registration to the notification service is received from the user. In step 1202, 
the permission held by the user is checked, and if the user had a permission to receive the notification service, an entry 
1503 and an entry 1504 are added to the notificalion service registration tables 1501 and 1502 according to permis- 
sions as indicated in Fig. 15. The entry 1503 is an user pointer to the user control table 1 100. The entry 1504 is a noti- 
5 fication control iniormation by a data access log. Both of the entries are stored in the notification service registration 
tables 1 50 1 and 1 502. If a permission held by the user is not suitable for the notification service, then step 1 204 reports 
that the user is not registered to the notification service registration labia 

[0057] It has already been described that the data updating unit 504 notifies the shared data updating for the users 
who are pre-registered for the shared data update notification request (user having permission 1). Next, how the updat- 
10 ing process of the shared data of step 1005 operates under the control of the data access log is described. 

[0058] In the entry 1504 of the notification sen/ice registration tables 1501 and 1502, rf the permission is unlimited, 0 
is registered. If the permission \s, limited to a record tfiat has actually accessed before. -1 is registered. If the permission 
is limited to a valid period of time from the last access, the period is registered in an hourly unit When 0 is being regis- 
tered as the entry, the differential data is transmitted unconditionally (depending on a requirement of the user, it is pos- 
ts slble to make selection so that the updated data only Is notified). When -1 is being registered as the entry, the user 
control table 1100 is accessed from the user pointer of the user control table 1 100, and the shared data update log 1 103 
to 1 105 are referred to see whether the user has accessed the record in the past, and if found to be so, the differential 
data is transmitted. When a vafid r^erence period is being registered in the entry, a last access time (update request 
issuance period) of the record is referred based on its log irrfornretion. arri if there is an access tog for the record, and 
20 if the last access time is within the valid reference period, the differential data is transmrtted. 
. . . [0059] When the server 1 1 0 receives ttie update request. It has already been described that the update request data ~ 
800 is trarKferred to the user who is registered for transferring the update reediest cbta 800 of the shared data (user 
having permission 2). The notification control in 908 is also processed as in tfie process described in step 1005. 
[0060] In the present system, if the user has pernnission 3. the user can request for a notification of the update log of 
25 shared data and a notification of the update request data 800 before updating tiie ^red data. The present system is 
provid^j with a port for inquiring the update log of shared data and a port for inquirir>g the update request data. In the 
present system, the update log of shared data is implemented by a log function of the database. When a user requests 
for a data to tiTe port for inquiring the update tog of shared data in tfie server by specifying a table, a record, and a 
period, then tJie server checks the permission heto by the user, inquires to the datak>ase, and returns the update tog 
30 within a requested period to the user. 

[0061 ] The user can request the update request data 800 before ifxlating the shared data by specifying the tatile only, 
^dfying the record only, or specifying tiie record that has actually accessed before only, alternatively, specifying the 
record in a vafid period of time from a last access only, or combining these conditions. 

[0062] When the server 110 receives the request above to its port for inquiring the update request data, upon recog- 

35 nizing the user permission, the server creates a list ttiat matches in conditton in an order of the oWest update request 
data receive, which is kept and controlled in a queue, and returns the fist to the user When tiie sever 1 10 receives the 
update request data 800, it obtains an exclusive-control lock of the update request queue and inserts the update 
request data 800 to the update request queue. However, a searching is performed by appropriately releasing the excfu- 
sive-oontrol lock of the update request queue. 

40 [0063] Now, the present system is provkied wrth a monitoring function of the shar^J data arxl a monitoring function 
of the predicting value. The monitoring functton monitors the shared data itseH and nrwnitors the predicting value which 
is calculated from the update request and whtoh is calculated by the server 110. That is, based on a product name, a 
remaining quantity and a dealing prtoe are monitored. The present system is provkied witii a mon'rtor registration port 
for receiving a nnonitor request of tiie shared data and a mon'rtor registratton port for receiving a monitor request of the 

45 predicting value. When the user selects ertiier one of tfie monitor registration ports by spec'rfying the table, the record, 
and the nnonitor condition, then the selected nrkonitor request is trar^smltted to the server. Upon chec^ng the permission 
held by tiie user, the server carries out a registration of the monitor request to a monitor queue 1 300 illusb^ted in Fig. 1 3. 
(Note that a monitor of ttie shared data is usable by all the users, however, a nrronitor of tiie predicting value requires 
permission 2 or a higher permission) The monitor queue 1300 Is provided for each recond. Each record is made as a 

so hash entry wherein a record name is used as a hiash key. A header 1 301 is the t^sh key. connected to a hash link 1 399 
comprised of monitor service registratton tables 1321 to 1323. In Hg. 13, only one queue is being illusti-ated, however, 
when registering the monitor request to tiie monitor queue, there is two queues including the monitor request of shared 
data and the nnonitor request of predicting value. 

[0064] In step 1007 of the shared data update process illustrated in Fig.10. after a data update notification process 
65 1006 is performed to the user, monitor conditions of tiie shared data in each record of the monitor service registration 
tatiles 1321 to 1323 are searched, and when the conditions are met by an updated change, the change is notified to 
the user. In tiie example of Fig. 1 3. an user of tiie monitor service registration tatjie 1 321 who is the first one in the mon- 
itor queue sets two conditions including a dealing value 1303 and a quantity 1304. However, nolrfication will be per- 
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formed when one o1 these corajitions is matched. 

[0065] The present embodiment describes the buying order and the selfing order in the commodities exchange, how- 
ever, the present invention is not only limited to such orders of the commodities, and can also be applied, for example, 
to the inventory control in supermarkets. In such a case, the Inventory supply request should correspond to the tjuying 

5 order, and the inveitory supply should correspond to the selling order. As long as the selling order and the buying order 
ot the present invention correspond to a demand and a supply respectively, an alternative embodiment can t>e adopted. 
[0066] Also, in the present embodiment, a period of time between 9 a.m. to 3 p.m. is set as the valid update request 
issuance period and a period of time between 9 a.m. to 9 p.m. is set as the update request reception period Other time 
periods can be applied, in minutes or in days units. 

10 [0067] Further, the present embodimem Is also operational when the update request reception period and the valid 
update request issuance period are ^ual. 

[0068] Furthermore, each nrxxlule and each unit can be implemented using the software or hardware, or can a 
combination of the software and the hardware. 

15 Industrial Applicability 

[0069] As descrft^ed alx>ve. the data updating system and the data updating method of the present invention updates 
the shared data based on the data update request issuing time, ther^ore, the data updating that does not rely on a 
conrvnunication connection status among the users and the sen/er Is pos^ble to Implement a fair data updating. 
20_ [0070] Also, by setting the update request reception period or by setting the valid update request issuance period, a 
systerh can operate flexibly. 

[0071 ] Further, the user can tiextoly use the system by setting the conditions for data updating. 
[0072] Furthenmore, a nee the shared data tpdate predicb'ng value is decided biased on the shared data update 
r^uest, the user can efflcierrtly evaluate their own shared data update request 
25 [0073] FurttTernnore, since an information to be transmrtt^ to each user terminal is selected by the permission held 
by the user, so that the server can efficiently transm'rt the information. 

[0074] Furthernrxjre, the server transrr^s the content of data update request entered from each user terminal or trans- 
mits the data tflxJate log only to the user terminal having the permission of greater than a certain strength, such that the 
server can transmit Information efficiently responding to a system load or a user's needs. 
30 [0075] Further, the server notifies the user terminal when updating the shared data, ^ the user can efficiently make 
a decision. 

[007S] Furthermore, snce a difference o1 the shared data tjefore and after updating Is included in the content of noti- 
fication, the user can readily reproduce the shared data. 

[0077] Furthenmore, a user terminal where the serv^ notifies to is the user terminaf that has made access to the 
35 sfwed data before updating the shared data, therefore, an operation responding to the system load and the user's 
needs is possible. 

[0078] Furthennore, a user terminal where the serv^ notifies to is the user terminal that has made access to the 
shared data in a valid period of time bdbre updating the shared data, therefore, an operation responding to the system 
load and the user's needs is poss%)fe. 
40 [0079] Furtherrriore. if an Information transmission request is made from the us& terminal, the server checks the 
access log to the shared data of the user ternrdr^, and only to those user t^minal ttiat has made access to the shared 
data before, the server responds to the information transmission request, therefore, an operation resporxfing 1o the sysr 
tern loads and the user's needs is possit)le. 

[0080] Furthermore, the server responds only when the user terrranal has made access to the shared data wHhin a 
45 valid period of time before the request, therefore, an operation responding to the system load and the user's needs is 
possible. 

[0081 ] Furthermore, the information transmission request is a transmission request for the content of a previous data 
update request already arrived in the server k>efbre updating process of the shared data, therefore, an operation 
responding to the system load and the user's ne^s is possible. 
60 [0082] Furthenmore. a user ternrBrwJ registers a condition for updating ttie shared data, artdi a shared data controller 
notifies the user terminal when the condition set in the server for data updating is met, therefore, the user can in^^ect 
tfie updating of shared data. 

[0083] Furthermore, a us^ terminal registers a condition to a server for updating the shared data, and the server noti- 
fies to the user terminal when the condition set by the user terrrdnai is met The condition is the shared data updating 
65 predicting value of the data updating request from the user ternrdnal or from another user terminal. 

[0084] Furthermore, the dock function perform an encryption that the system controller only can decrypt, therefore, 
thus Is effective by mear^ of preventing an urtauthoriz^ decryption when performing a sequential data updating. 
[0085] Furthernrrore. the clock function has a user sujthentication function, therefore, an unauthorized access is pre- 
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vented by specrfying the user. 

[0086] Furthermore, since the server stores to a memory a shared data update request from the user terminal, there- 
fore, when a trouble occurs in a management system, a received update data is correctly reflected to the shared data 
after restoring the received update data to the management system. 

[0087] Furthermore, the shared data updating request comprises the selling order or buying order including the first 
condition and the quantity. The shared data updating request is stored in the shared data update r^uest queue in an 
order of the data update request issuing time. For the buying order, the selling order that meets the first condition of the 
buying order is searched in an order. When the first condrlion matches, a next concfition which is quantity is searched. 
On contrary, for the selling order, if the first condition of the buying order is searched in an order, and when the first con- 
dition nnatches, the next condition which is quantity is searched. Therefore, the buying order and the selling order with 
matcNng conditions are effectively searched. 

Claims 

1 . A data updating system, comprising: 

a plurality of user terminals; arxJ 

a server for controlling a shared data among users; 

wherein the plurality of user terminals and the server include clock modules for keeping a time syrx:hronized 
between the user terminal and the server; 

wherein the user terminal includes an update request transmissio« processing unit for transmitting a shared 
data update request to the server by attaching a tinne obtained from the dock module as a data update issuing 
time when representing a shared data updating, and ior repeat^ly transmitting the shared data update 
request in keeping the data update issuance time unchanged until the shared data update request is received 
by the server; and 

wherein the server includes a shared data control module for deciding an ifxlating order of the shar«j data 
update r^uest based on an attached data update issuing time of the shared data update request recaved 
from the user terminal. 

2. The data updating system according to claim 1, wherein the shared data control module includes an update rule 
control unH for setting an update request reception period, and an update rajuest control unit for receiving the 
shared data update request received within the update request reception period. 

3. The data updating system according to claim 2. wherein the update rule control unit further sets a valid update 
request issuance period which is included in the update request r^eption period; 

wherein the update request control unit receives a shar«j data update request for which a data update 
request issuance perkxl of the shared data update request received is within the vaftd update request issuance 
period. 

4. The data tpdating system according to claim 3. wherein the update data request transmisaon processing unit 
transmits ttie shared data update request including a data updating condition to the server; 

wh^-ein the shared data control module includes a data updating unit for cheddng the data updating condi- 
tion included in the shared data update request in an order of data update request issuance time after the update 
request reception perkxi expires, dec'ding a shared data update value based on the shared data update request 
when the update corrdition is met and updating the shared data to the shared data ufxlating value. 

5. The data updating system according to daim 4, wherein tiie data updating unit checks the data updating condition 
included in the shared data update request which is already receved within the vaRd update request issuance 
period in an order of the update request issuing time, and decides a shared data update predicting value fciased on 
the shared data update request when the update condition is met 

6. The data updating system according to daim 1 , wherein the shared data control module Indudes a user notification 
unit for giving one of permisaons to the user terminal from permissions dassif ied by strer>gths. and selecting infor- 
mation which is transmitted to the user terminal based on the permission. 

7. The data updating system according to daim 6, wherein the user notification unit transmits an update log of the 
shared data only to a user to-minal having a pennission of a certain strength. 
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8. The data updating system according to claim 6, wherein the user notification unit transmits a content of the data 
updating request received from the user terminals only to a user terminal having a permission of a certain strength. 

9. The data updating system according to claim 1 , wherein the shared data control module includes a user notification 
5 unit for notrfying the shared data to the user terminal when the shared data is updated. 

1 0. The data updating system according to claim 9. wherein the user notification unit includes a1 least a differential data 
between the shared data before updating and after updating in a content of the notification. 

to 11. The data updating system according to daim 9, wherein the user rKrtification unit notifies to a user terminal that has 
accessed the shared data before updating the shared data. 

1 2. The data updating system according to claim 9, wherein the user notification unit notifies to a user terminal that has 
accessed the shared data within a pre<letermined period before updating the shared data. 

15 

13. The data updating system accorcfing to claim 1, wherein the user terminal transmits an information transmission 
request to the server, and wherein the shared data control nrodule includes a user notification unit for receiving the 
information trartsmission request from the user terminal, checking an access log, and re^onding to the inforamtion 
transmission request if the user ternninal has accessed the shared data before receiving the information transnnis- 

20 sion request. 

14. The data updating system according to daim 13. wherein the user notification unit responds to the information 
transmission request if the user terminal has accessed the shared data within the pre-determined period before 
receiving the information transmission request. 

25 

15. The data updating system according lo daim 13. wherein the information transmission request from the user ter- 
minal is a transmission request of the content of the data updating request already arrived to the server before a 
shared data updating process. 

30 16. The data updating system according to claim 1 , wherein the user terminal transrrrits a condition for nxxiitoring the 
shared data updating: 

wherein the ^lared data control nxxjule indudes a user notification unit for registering a transmitted condi- 
tion, and notifying the shared data updating to the user terminal when the cortdrtion is met at the stored data updat- 
ing. 

36 

17. The data updating system according to claim 5. wherein the user terminal Iransmils a condition for monitoring the 
shared data updating; 

wherein the shared data contrd oKXlule includes a user notification unit for registering the transmitted con- 
dition, and notifying to the user terminal that the shared data updating predicting value meets the condition when 
40 the shared data updating predicting value meets the condition. ^ ^ ^ 

18. The data updating system according to daim 1, wher«n the dock nrxxJule includes an encryption unit. 

19. The data updating system according to daim 1, wherein the dock module includes a user terminal auth^ication 
45 function. 

20. The data updating system according to daim 1 , wherein the server indudes a memory unit for storing a shared 
data updating request queue, and arranging the sfwed data update request received from the user terminal by the 
shared data control nrxxlile in an order of the data update request issuance time. 

50 

21 . A data updating method for a computer systems having a plurality of user terminals, and a serv^ for controlling the 
shared data among the users, wherein the plurality of user terminals and the sender re^ectively have dock mod- 
ules for keeping a time, the data updatir^ method conprising the steps of: 

ss synchronizing a time between the dock modules of a plurality of user terminals and the clock module of the 

server; 

t>y the user terminal, attaching a time obtained from the dock module as a data update request fesuance time 
to a shared data update request when requesting a shared data update, and transmitting the shared data 



14 
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update request to the server, and repeatedly transmitting the shared data update request in keeping the data 
update request issuance time unchanged until the shared data update request Is received at the server; and 
by the server, receiving the shared data update request from the user terminal and deciding the updating order 
of the shared data based on an attached data update request issuance time attached to the shared data 
update request received. 

The data updating method according to claim 21 , wherein the shared data update request is one of a selling order 
and a twying order which includes a first condition and a quantity, wherein the shared data update request is stored 
in a memory unit of the server in a format of shared data update request queue in an order of the data update 
request issuance time. 

wherein the data updating method comprises the steps of: 

a) checking by executing one of the steps of (a1) to (a3), depending on a state of the shared data updating 
request queue stored in the menrtory unit of the server: 

a1) completing the data updating process when neither the selling order nor the buying order is stored in 
the shared data update request queue stored in the memory unit of the server; 

a2) taking the buying order as a main order and taking the selling order as a dealing order when a top of 
the shared data update request queue stored In the memory unit of the server is the buying order, and 
advancing to a first condtion conrparing step (b); and 

a3) taking the selling. order as a main order and the Ixjying order as a dealing order when a top of the 
shared data updating request queue stored in the memory unit of the server is the selling order, and 
advancing to the first condition comparing step (b); and 

b) comparing the first cor^Jition by reading the dealing order in an order from the shared data updating request 
queue stored in the memory unit of the server, and executing one of the steps depending on an availability of 
a dealing order that matches in the first condition with the main order; 

b1) if there is no matching in first condition, deleting the main order from the shared data update request 
queue as a non-established main order and returning to the checking st^ (a); 

b2) if the first condition matches, comparing the buying quantity and the selling quantity, and executing one 
of the following sieps based on a result of comparing; 

b2^) if the buying quantity is exceeding the selling quantity, non-establishing the kjuying order and the 
selling order, ard reading a next dealing order from the ^lared data update request queue, and return- 
ing to the first condition conrparing step; 

b22) if the buying quantity is same with the selling quantity, establishing the buying order and the sell- 
ing order, deleting tiie txiying order and the selling order from the shared data update request queue, 
and returning to the checking step (a>;'and 

b23)if the selling quantity exceeds tiie buying quantity, establishing the selling order and tiie buying 
orxfer. deleting the ttuying order froTh the shared data update request queue, and replacing sdling 
quantity to an exceeding buying quantity, updat ng and storing the queue data of the selling order, and 
returning to the checking step (a). 
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Fig.4 
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Fig. 5 
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Fig.6 
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Fig.7 
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Fig. 8 
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Fig. 9 
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Fig. 10 
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Fig. 11 
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Fig. 12 
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Fig. 13 
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Fig. 14 
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Fig. 15 
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